Seis sigmas se pueden resumir como una metodología. En la figura 16.1 se muestran los pasos de seis sigmas. Sin embargo, seis sigma es mucho más que una metodología; es una filosofía y una cultura.
Para mas información sobre seis sigma y administración de la calidad, visite el sitio Web del juran Center en la carlson School of management de la university of minnesota en twin cities (www.csom.umn.edu). En 2002 el juran center emitió un manifiesto para apoyar y fomentar la calidad. Los autores de este libro firmaron el manifiesto en ese momento y sinceramente estamos de acuerdo con sus principios.
Joseph M. juran dijo: "Toda mejora de la calidad ocurre proyecto tras proyecto y de ninguna otra forma" (juran, 1964). Los análisis de sistemas y gerentes de proyecto deben tomar muy en serio esta afirmación.
RESPONSABILIDAD DE LA ADMINISTRACIÓN DE LA CALIDAD TOTAL
En términos prácticos, gran parte de la responsabilidad por la calidad de los sistemas de información recae en los usuarios de éstos y en los directivos. Para que la TQM se vuelva una realidad en los proyectos de sistemas, deben darse dos condiciones. Primero, debe existir un apoyo organicional incondicional por parte de los directivos, lo cual es distinto a simplemente respaldar el nuevo proyecto de los directivos. Este apoyo significa establecer un contexto para que los directivos consideren seriamente cómo afecta su trabajo la calidad de los sistemas de información y la información misma.
Es necesario que tanto el analista como la empresa se comprometan desde el principio con la calidad para lograr le meta de calidad. Este compromiso da como resultado un esfuerzo uniformemente controlado hacia la calidad durante todo el ciclo de vida del desarrollo de sistemas, y esta en marcado contraste con tener que dedicar gran calidad de esfuerzo para resolver problemas al fin del proyecto.
El apoyo organicional para conseguir calidad en sistemas de información de administración se puede lograr al proporcional el tiempo en el trabajo para los círculos de calidad de SI, los cuales consisten de seis a ocho pares organizacionales específicamente responsable de considerar cómo mejorar los sistemas de información y como implementar las mejoras.mediante el trabajo en los círculos de calidad de SI o a través de otro mecanismos ya colocados, la administración y usuarios deben desarrollar lineamientos para los estándares de calidad de sistemas de información, preferentemente los estándares se diseñaran cada vez que un nuevo sistema o una modificación mayor se proponen formalmente para el equipo de análisis de sistemas.
No es fácil crear los estándares de calidad, pero es posible y se ha hecho. Parte del trabajo del analista de sistema es alentar a usuarios a que cristalicen sus expectativas acerca de los sistemas de información y sus interacciones con éstos.
Los estándares de calidad departamentales se deben comunicar mediante retroalimentación para el equipo de análisis de sistemas. Normalmente el equipo esta sorprendido por lo que se ha desarrollado. Las expectativas generalmente son menos complejas de lo que los analista experimentados saben se podría hacer con un sistema. Además los problemas humanos que se han omitido o menospreciado por el equipo del
Analista se podrían diseñar como extremadamente urgentes en los estándares de calidad para los sistemas de información ayudaran al analista a evitar errores costosos en el desarrollo de sistemas no desarrollado o innecesario.
OPORTUNIDADES DE CONSUTARIA 16:1
LA CALIDAD DE MIS NO ES OBLIGATORIA
"Merle, ven aquí y echa un vistazo a estos informes de fin de semanas, suplica portia. Como uno de los gerentes del comité de aseguración de la calidad/ grupo de trabajo de SI, compuesto por seis integrantes, portia ha estado examinado la salida del sistema producida por el prototipo para su departamento de marketing. El equipo de análisis de sistemas le ha permitido que revise la salida. "Merle Chat se encamina hacia el escritorio de portia y da una mirada a los documentos que ella le extiende. " ¿Por qué?, ¿Cuál es el problema?", pregunta. "A mi me parece que están bien. Creo que le estas dando demasíada importancia a esta grupo de trabajo. Se supone que también debemos hacer nuestro otro trabajo, ya sabes, " Merle da la vuelta y regresa a su escritorio ligeramente perturbado por la interrupción. " Merle, ten un poco de compasión. Es verdaderamente tonto soportar estos informes tal como están. No puedo encontrar nada de lo que necesito, y se supone que tengo que indicarles a todos los demás en el departamento qué parte del informe deben leer. Por una parte, estoy decepcionada. Este informe es descuidado. No le encuentro ningún sentido. Es tan solo una copia de la salida que estamos recibiendo ahora. De hecho, parece peor. Lo voy a presentar en la próxima reunión del grupo de trabajo, manifiesta insistentemente portia.
Merle voltea a verla y dice: la calidad es su responsabilidad, portia. Si el sistema no esta dándonos buenos informes, ellos lo agregaran cuando Todo esté junto. Nada más estás provocando problemas. Estas actuando como si ellos valoraran realmente nuestra información. Yo no le dedicaría tiempo de mi día, mucho menos haría su trabajo. Ellos son inteligentes, dales la oportunidad de que deduzcan lo que necesitamos. Portia mira a Merle inexpresivamente, y poco a poco comienza a enfadarse, dice .tú has asistido a cuatros reuniones. Nosotros somos los únicos que conocemos el negocio. La idea esencial de TQM es decirles lo que necesitamos, entonces no podemos quejarnos. Esto lo plantearé la próxima vez que nos reunamos. "
¿Qué tan eficaz cree que será merle para comunicar sus normas de calidad al equipo de análisis de sistemas y a los miembros del grupo de trabajo de SI?
Responda en un párrafo. ¿si los analistas de sistemas pueden percibir la reunión de merle para trabajar con el grupo de trabajo en el desarrollo de las normas de calidad, qué le diría para convencerlo de la importancia de la participación de los usuarios en la TQM? haga una lista de argumentos que apoye el uso de la TQM. ¿Cómo puede responder el equipo de análisis de sistemas a las inquietudes que plantea portia? explique su respuesta en un párrafo.
REPASO ESTRUCTURADO
Una de las acciones de administración de la calidad mas eficaces que puede emprender un equipo de análisis de sistemas es hacer repasos estructurados de manera rutinaria. Los repasos estructurados son una forma de usar expertos para monitorial la programación y el desarrollo general del sistema, señalar los problemas y permitir al programador o analista responsable de dicha parte del sistema hacer los cambios correspondientes.
Los repasos estructurados involucran por lo menos a cuatros personas: la persona responsable de la parte del sistema o subsistema que se revisará (un programador o analista) o coordinador del repaso, un programador o analista experto y un experto que toma notas acerca de las sugerencias.
Cada persona que participa en un repaso tiene un papel especial que cumplir. El coordinador se encarga de asegurar que otros cumplan los papeles que se le asigne y de que realicen las actividades establecidas. El programador o analista Este para escuchar, no para defender su punto de vista, racionalizar o discutir un problema. El programador o analista experto tiene que señalar los errores o problemas potenciales, sin especificar como se debe resolver. El tomador de notas registra lo que se dice con el fin de que los demás participantes puedan interactuar sin ningún problema.
Los repasos estructurados se pueden hacer siempre que una parte de la codificación, de un subsistema o de un sistema esté terminada. Simplemente asegurarse de que el subsistema bajo revisión sea comprensible fuera del contexto al que pertenece. Los repasos estructurados son especialmente adecuados en un enfoque de administración de la calidad total cuando se realiza durante todo el ciclo de vista de desarrollo de sistemas. El tiempo para realizarlos debe ser de media hora a una hora cuando mucho, lo cual implica que debe coordinarse muy bien. En la figura 16.2 se muestra un formulario útil para organizar el repaso estructurado e informar sus resultados. Debido a que el repasos estructurado tomas tiempo, no abuse de ellos.
Utilice los repasos estructurados para obtener (y después emprender acciones acordes con) retroalimentación valiosa desde una perspectiva que le falte. Al igual que con todas las medidas de aseguramiento de la calidad, el propósito de los repasos es evaluar el producto sistemáticamente de manera continua en lugar de esperar hasta la terminación del sistema.
DISEÑO Y DESARROLLO DE SISTEMAS
En esta sección definimos los diseños de sistemas ascendente (de abajo a arriba o bottom-up) y descendente (de arriba abajo o top-down), así como también el enfoque modular para la programación. Discutimos las ventanas de cada uno, así como también las preocupaciones que se deben observar al emplear un enfoque descendente o uno modular.
También discutimos las propiedades de los enfoques descendente y modular para ayudar en el aseguramiento de la calidad de los proyectos de sistemas.
Diseño ascendente este diseño se refiere a identificar los procesos que necesitan computarizarse conformes surgen, analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato. Los problemas que requieren computarizarse normalmente se encuentran en el nivel mas bajo de la organizacion. Con frecuencia este tipo de problemas son estructurados y por lo tanto son más sensibles a la computación; también son los más rentables. Por lo tanto, el nombre ascendente se refiere al nivel inferior en el cual se introduce primero la computación. Por ejemplo, con frecuencia los negocios toman este enfoque para el desarrollo de sistemás al adquirir software comercial para la contabilidad, un paquete diferente para la programación de producción y otros para el marketing.
Cuando la programación interna se hace con un enfoque de ascendente, es difícil interconectar los subsistemas de manera que se desempeñen fácilmente como sistema. Es muy costoso corregir las fallas de la interconexión y muchas de ellas no se descubren, sino hasta que se completa la programación, cuando los analistas intentan reunir el sistema en la fecha limite señalada para la entrega. En esta situación, hay poco tiempo, presupuesto o paciencia del usuario para la depuración de las interconexiones delicadas que se han ignorado.
Aunque cada subsistema aparenta conseguir lo que quieren, al considerar el sistema global hay series limitantes para tomar un enfoque de ascendente. Una es que hay duplicidad de fuerza software e incluso introducir los datos. Otra es que se introducen datos inválidos en el sistema. Una tercera, y quizás las desventajas mas serias del enfoque ascendente, es que no se consideran los objetivos organicionales globales, y por lo tanto dicho objetivos no se pueden cumplir.
Diseño descendente es fácil visualizar este enfoque: como se muestra en la figura 16.3 significa ver una descripción amplia del sistema y después dividirla en partes más pequeñas o subsistemas. El diseña descendente permite a los analista de sistemas determinar primero los objetivos organicionales globales, así como también determinar como se reúnen mejor en un sistemas global. Después el analista divide dicho sistemas en subsistemas y requerimientos.
El diseño descendente es compatible con el pensamiento general de sistema que se discutió en el capitulo 2. Cuando los analistas de sistemas utilizan un enfoque descendente están pensando en que las interrelaciones e interdependencia de subsistemas se adaptan a la organización de existencia. el enfoque descendente también proporciona el énfasis deseable en la colaboración o interconexiones que los sistemas y sus subtemas necesitan, cual falta en el enfoque ascendente.
Las ventanas de usar un enfoque descendente para el diseño de sistemas incluyen evitar el caos de intentar diseñar un sistema de repente. Como hemos visto, planear e implementar sistemas de información y administración es increíblemente complejo intentar colocar todos los subsistemas en un lugar ejecutable enseguida es casi un fracaso seguro.
Una segunda ventana de tomar un enfoque descendente para diseñar es que permiten separar a los equipos de análisis de sistemas para trabajar en paralelo en diferentes subsistemas, lo cual puede ahorrar mucho tiempo. El uso del equipo para el diseño de subsistemas se ajusta particularmente bien a un enfoque de control de calidad total.
Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado con un enfoque ascendente; evitar que los analistas de sistemas se metan tanto en los detalles que pierdan de vista lo que se supone que el sistema hace.
Hay algunas dificultades con el diseño descendente que el analista de sistema necesita saber. La primera es el riesgo de que el sistema se divida en subsistemas "errores". Se debe por atención a las necesidades que se traslapen y a la comparticion de recursos de manera que la partición en subsistemas tenga sentido para todos los sistemas. Además, es importante que cada subsistema solucione el problema correcto.
Un segundo riesgo es que una vez que se hacen las decisiones de un subsistema, sus interfaces se podrían descuidar o ignorar. Es necesario destallar de quien es la responsabilidad de las interfaces.
Una tercera advertencia es acompaña al uso de un diseño descendente es que los subsistemas se deben reintegrar eventualmente. Los mecanismos para la reintegración se necesitan poner en funcionamiento desde el principio. Una sugerencia es negociar información regular entres los equipos del subsistema; otra es usar herramientas que permiten flexibilidad si se requieren cambios para los subsistemas interrelacionados.
La administración de calidad total y el enfoque descendente para diseñar puede estar relacionada. El enfoque descendente proporciona el grupo de sistemas con una decisión más natural de usuarios en grupos de trabajos para subsistemas. Los grupos de trabajos establecidos de esa forma después pueden servir a una función dual como círculos de calidad para el sistema de información de administración. La estructura necesaria para el control de calidad está en el lugar, así como la motivación apropiada para obtener el subsistema para lograr las metas departamentales que son importantes para los usuarios involucrados.
DESARROLLO MODULAR
Una vez que se toma el enfoque del diseño, el enfoque modular es útil en la programación. Este enfoque implica dividir la programación en partes lógicas y manejables llamada módulos. Este tipo de programación funciona bien con el diseño descendente por da énfasis a las interfaces entre los módulos y no los descuida hasta el final del desarrollo de sistema. Idealmente, cada modulo individual debe ser funcionalmente cohesivo de manera que encargue de realizar una sola función.
El diseño de progre modular tienes tres ventajas principales. Primero, los módulos son más fáciles de escribir y de depurar porque prácticamente son independientes. Rastrear un error en un modulo es menos complicado, debido a que un problema en un modelo no debe causar problemas en otros.
Una segunda ventaja del diseño modular es que los módulos son más fáciles de mantener. Normalmente las modificaciones se limitarán a unos módulos y no seguirán en todo el problema.
Una tercera ventaja del diseño modular es que los módulos son más fáciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del código de un modulo y entender su función.
Algunos lineamientos para la programación modular incluyen lo siguiente:
1. mantener cada modulo de un tamaño manejable (incluir a la perfección una solo función).
2. poner particular atención a la interfaces críticas (los datos y variables de control que se pasan a otros módulos).
3. minimizar el numero de modulo que el usuario debe modificar al hacer los cambios.
4. mantener las relaciones jerárquicas establecidas en las fases descendentes.
MODULARIDAD EN EL ENTORNO DE WINDOWS
La modularidad se está volviendo muy importante. Microsoft desarrolló dos sistemas para vincular los programas en un entorno de Windows. El primero se llama intercambio dinámico de datos (DDE), el cual comparte códigos al usar archivos de bibliotecas de vínculos dinámicos (DLL). Al usar DDE, un usuario puede almacenar datos de un programa quizás en una hoja de cálculos tal como Excely después usar dichos datos en otros programas, por decir, en un paquete de procesamiento de texto tal como Word para Windows. El programa que continúe los datos originales se denominan servidor y el programa que los usa se llama cliente, los datos se actualicen automáticamente y se refleje los cambios hechos en los archivos de hoja de cálculos del servidor desde la última vez que se abrió dicho archivo de procesamiento de texto. (Véase el capitulo 17 para una discusión amplia del modelo/servidor).
Uno de los archivos de la DLL normalmente usados es COMMDLG.DLL, el cual contiene los cuadros de diálogos de Windows para Abrir Archivos, Guardar Archivos, Buscar e Imprimir. Una ventaja de usar este archivo es que los programas tendrán la misma apariencia y funcionamiento que otros programas de Windows. También acelera el desarrollo, debido a que los programadores no tienen que escribir el código contenido en los archivos DLL más comunes.
Un segundo enfoque para vincular programas en Windows se denomina vinculación e incrustación de objetos (OLE). Este método de vincular programas es superior a DDE porque está ligado a los datos y gráficos de la aplicación. Mientras que DDE utiliza un enfoque de cortar y pagar para vincular datos y no retiene el formato, OLE retiene todas las propiedades de los datos creados originalmente. Este enfoque orientado a objetos (Véase en el capitulo 18 para una discusión de principios orientados a objetos) permite al usuario final pertenecer a la aplicación del cliente y evitar los datos originales en la aplicación del servidor. Con OLE, cuando un usuario final hace clic en el objeto incrustado, se despliega una barra de herramienta que permite la edición visual.
USO DE DIAGRAMAS DE ESTRUCTURA PARA DISEÑAR SISTEMAS
Las herramientas recomendadas para diseñar un sistema modular descendente se denomina diagrama de estructura. Este grafico simplemente es un diagrama que consiste de cuadros rectangulares, los cuales representan los módulos, y de flechas de conexión.
La figura 16.4 muestra tres módulos que se etiquetan como 000, 100 y 200 y se conectan mediante líneas de ángulos rectos. Los módulos del nivel superior se numeran por 100s o 1,000s y los módulos de nivel inferior se numeran por 10s o 100s. Esta enumeración permite a programadores insertar módulos que se usan un número entre los números de módulos adyacentes. Por ejemplo, un modulo insertado entre los módulos 110 y 120 recibiría el numero 115. Si se insertarán dos módulos, los números podrían ser 114 y 117. Estos esquemas de numeración varían, dependiendo de los estándares organicionales usados.
A los datos de las líneas de conexión, se dibujan dos tipos de flechas. Las flechas con los círculos vacíos se denominan parejas de datos y las flechas con los círculos rellenados se denominan bandejas de control o interruptores. Un interruptor es lo mismo que una bandeja de control acepto por que está limitado por dos valores: si o no. Esta flechas indican que algo se pasa hacia abajo al modulo inferior o arriba al superior.
El analista debe mantener a la perfeccionaste acoplamiento al mínimo. Cuando hay pocas parejas de datos y bandejas de control en el sistema, lo más fácil es cambiar el sistema. Cuando finalmente se programan estos módulos, es importante pasar el menor número de parejas de datos entre los módulos.
Aun mas importante es que se debe evitar las bandejas de control numerosas. El control se diseña para ser pasado de los módulos del nivel inferior a los del nivel superior en la estructura. Sin embargo, en rara ocasiones será necesario pasar el control hacia abajo en la estructura. Las bandejas de control deciden qué parte de un modelo se ejecuta y están asociado con las instrucciones IF…THEN…ELSE… y otros tipo similares de instrucciones. Cuando el control se pasa en forma descendente, se permiten que un modulo de nivel inferior tome una decisión y el resultado en un modulo que decenpeña dos tareas diferentes. Este resultado rompe con el modelo de modulo funcional: un modulo solo debe desempeñar una tarea.
La figura ilustra que parte de un diagrama de estructura para agregar nuevos empleados. El programa lee un archivo de TRANSACCION DE EMPLEADO y verifica que cada registro en el archivo únicamente tenga datos aceptables. Los informes se imprimen por separados para los registros válidos e inválidos, proporcionando un rasgo para auditoria de todas las transacciones.
El informe que contiene los registros inválidos se envía al usuario para la corrección de errores. Los registros que son validos se ponen en un archivo de transacción válido, el cual se pasa a un programa separado para actualizar el archivo MAESTRO DE EMPLEADOS. El modulo 200, AGREGA NUEVOS REGISTRO DEL EMPLEADO, representa la lógica de agregar un registro. Debido a que el modulo 230 se usa para imprimir ambos informes, se debe enviar una bandera de control hacia abajo para indicar al modulo que informe imprimir. De esta manera la lógica del modulo 230 se controla por completo mediante una instrucción IF, la cual se ilustra en la figura 16.6.
La figura 16.7 muestra la forma correcta de diseñar la estructura por debajo del modulo 200, AGREGAR NUEVO REGISTRO DEL EMPLEADO. Aquí, cada función de impresión se ha puesto en un modelo separado y las banderas de control solo se pasan a la estructura al modulo del nivel superior.
FIGURA 16.6
El pseudocódigo para el módulo 230 ilustra el efecto de pasar de forma descendente un interruptor.
Modulo 230-imprimir lista del empleado válida o línea inválida
IF INTERRUPTOR DEL EMPLEADO VÁLIDO = ºYº
Mover NÚMERO DEL EMPLEADO a LISTA DEL EMPLEADO VÁLIDA Mover NOMBRE DEL EMPLEADO a LISTA DEL EMPLEADO VÁLIDA Mover TRABAJO DEL EMPLEADO a LISTA DEL EMPLEADO VÁLIDA
Mover DEPARTAMENTO DEL EMPLEADO a LISTA DEL EMPLEADO VÁLIDA
Mover NÚMERO TELEFÓNICO DEL TRABAJO DEL EMPLEADO a LISTA DEL EMPLEADO VÁLIDA
Mover FECHA DE CONTRATO DEL EMPLEADO a LISTA DEL EMPLEADO VÁLIDA DO IMPRIMIR LISTA DEL EMPLEADO VÁLIDA ELSE
Mover NÚMERO DEL EMPLEADO a LINEA INVÁLIDA Mover NOMBRE DEL EMPLEADO a LINEA INVÁLIDA Mover TRABAJO DEL EMPLEADO a LINEA INVÁLIDA
Mover DEPARTAMENTO DEL EMPLEADO a LINEA INVÁLIDA
Mover NÚMERO TELEFONICOO DEL TRABAJO DEL EMPLEADO a LINEA INVÁLIDA
Mover FECHA DE CONTRATO DEL EMPLEADO a LINEA INVÁLIDA DO IMPRIMIR LINEA INVÁLIDA ENDIF
También se debe examinar los datos que se pasan a través de las parejas de datos. Es mejor pasar sólo los datos requeridos para realizar la función del módulo. Este enfoque se denomina acoplamiento de los datos. El paso excesivo de datos se denomina acoplamiento de sello, y aunque es relativamente imnofencivo, reduce las posibilidades de crear un módulo reutilizable.
La figura 16.8 ilustra este concepto. Aquí, el módulo EDITAR NUEVO CLIENTE pasa el REGISTRO DEL CLIENTE al módulo EDICTAR NÚMERO TELEFONICO DEL CLIENTE, donde NUMERO TELEFONICO, un elemento encontrado en el REGISTRO DEL CLIENTE, se válida, y una bandera de control se pasa atrás al módulo EDICTAR NUEVO CLIENTE. EL TIPO DE ERROR (si no hay algunos), uno que contiene un mensaje de error tal como CÓDIGO DE ÁREA INVÁLIDOS O EL NUMERO TELEFONICO NO ES NUMÉRICOS, también se pasa hacia arriba. El mensaje se podría imprimir o desplegar en pantalla.
Aunque dichos módulos son bastante fáciles y crear y modificar cada vez que es necesario editar un número telefónico de un registro fuente diferente, se debe crear un nuevo modulo similar al EDICTAR NUMERO TEEFONICO DEL CLIENTE. Además, si la forma del número telefónico esta di validando los cambios como ocurre cuando se debe agregar un nuevo código de área o un código de país internacional, cada uno de estos módulos del nivel inferior se debe modificar.
Debido a que modulo de nivel o requiere ninguno de los otros elementos en el REGISTRO DEL CLIENTE, la solución es pasar solo el NIMERO TELEFONICO al modulo del nivel inferior. El nombre del modulo en este escenario cambia a EDICTAR NÚMERO TELEFONICO y se podría usar para editar cualquier número telefónico: un numero telefónico del cliente o un número telefónico del empleado. Los módulos del lado derecho de la figura ilustran este concepto. Cuando cambia las reglas para validar el número telefónico, solo se necesita EDITAR NIMERO TELEFONICO, sin tener en cuenta cuantos programas utilizan dicho modulo. Con frecuencia estos módulos de uso general se ponen en un programa compilado por separado denominado subprograma, función o procedimiento, dependiendo del lenguaje del programa usado.
Como se muestra en la figura 16.9, el bucle es otro símbolo usado en los diagramas de estructura. Este símbolo indica que algunos procedimientos encontrados en los módulos 100 y 200 serán respetados hasta terminar. Este ejemplo implica que LLER REGISTRO DEL CLIENTE y EDITAR REGIETRO DEL CLIENTE se repitan hasta que todo el registro del cliente se complete. Después se clasifican en el modulo 300, pero como puede ver, se puede clasificar de tres formas diferentes: por nombre, código postal o código de área. Para mostrar que parte, pero no toda, de las clasificaciones se realizará, se usa otro símbolo, un diamante. Observe que el diamante no indica cual de los tres módulos se desempeñará, ni el bucle indica que modulo se repetirán estos símbolos pretenden deliberadamente ser generales no específicos.
DIBUJO DEL DIAGRAMA DE ESTRUCTURA
Obviamente, los diagramas de estructura se deben dibujar de arriba hacia abajo, pero ¿dónde se empiezan los procesos que serán los módulos? Probablemente, el mejor lugar para buscar esta información es en el diagrama de flujo de datos (véase el capitulo 7).
Al trasformar un diagrama de flujos de datos en un diagrama de estructura, se debe tener en cuenta varias consideraciones adicionales. El diagrama de flujos de datos indicara la secuencia de los módulos en un diagrama de estructura. Si un proceso proporciona entrada a otro proceso, los módulos correspondientes se deben acompañar en la misma secuencia. La figura 16.10 es un diagrama de flujos de datos para preparar un informe de clasificación del estudiante.
Observe que el proceso 1, LEER REGISTRO DE CALIFICACION, proporciona entrada para el proceso 2, LEER REGISTRO DEL CURSO, Y PARA EL PROCESO 3, LEER REGISTRO DEL ESTUDIANTE. En la figura 16.11 se ilustra el diagrama de estructura creado para este diagrama. Observe que el modulo 110, LEER REGISTRO DE CALIFICACION, se debe ejecutar primero. Después se deben ejecutar los procesos 2 y 3, pero debido a que no proporcionan entrada para otros, el orden de estos módulos (120 y 130) en el diagrama de estructura no es importante y se podría invertir sin afectar Los resultados finales. Los procesos 1 y2 proporcionan entrada para el proceso 4, CALCULAR MEDIA DE PUNTO DE CALIDAD (también conocido como modulo 140). El proceso 5, IMPRIMIR INFORME DE CALIFICACION DEL ESTUDIENTE (modulo 150), recibe flujos de datos de todos los demás procesos y debe se el ultimo modulo en ser ejecutado.
FIGURA 16.10
Diagrama de flujos de datos para imprimir un informe de calificación de estudiante
Si un proceso se divide en un diagrama de flujo de datos de hijo, el modulo correspondiente para el proceso padre tendrá módulos subordínales que correspondan a los procesos encontrado en el diagrama de flujo. El proceso 5, IMPRIMIR INFORME DE CALIFICACION DEL ESTUDIANTE, tiene cuatros flujos de datos de entrada y uno de salida y por ello es buen candidato para un diagrama hijo. En la figura 16.12 se ilustra en el diagrama 5, los detalles del proceso 5. Los procesos en el diagrama 5, traduce los módulos subordinados al modulo 150, IMPRIMIR INFORME DE CALIFICACION DEL ESTUDIANTE.
TIPOS DE MÓDULOS
Los módulos del diagrama de estructura entran en una de las tres categoría generales: (1) control, (2) transformacional ( a veces denominado trabajador) o (3) funcional. Al producir un diagrama de estructura que es fácil de desarrollar y modificar se debe tener cuidado, de no mezclar los diferentes tipos de módulos.
Los módulos de control normalmente se encuentran siempre en la parte superior del diagrama de estructura y contienen las lógicas para decenpeñan los módulos del nivel inferior. Los módulos de control podrían estar, o no estar representado en el díagrama flujo de datos. Los tipos de instrucciones que normalmente están en los módulos de control son IF, PERFORM DO. Las instrucciones detalladas tal como ADD y MOVE normalmente se mantienen al mínimo. Con frecuencia la lógica de control es la mas difícil de enseñar por lo tanto, los módulos de control no deben de ser muy grande. Si un modulo de control tiene mas de nueve módulos subordinado, se deben crear nuevos módulos de control que sean subordinado de modulo de control original. La lógica de un modulo de control se podría determinar desde un árbol de disición o una tabla de decisión. Una tabla de decisión con demasiada reglas se deben dividir en varias tablas de decisión, con la primera tabla llamando a ejecución a la segunda tabla. Cada tabla de decisión produciría un modulo de control (véase el capitulo 9 para mas información de los árboles y la tabla de decisión).
Los módulos transformacionales son aquello creados de un diagrama de flujos de datos. Normalmente desempeñan una sola tarea aunque varias tareas secundarias se podrían asocial con la principal. Por ejemplo, un modulo denominado IMPRIMIR LINEA TOTAL DEL CLIENTE podría formatear toda la línea, imprimir la línea, agregarla a los totales finales y establecer los totales del cliente a cero en la preparación para acumular las cantidades del siguiente cliente. Los módulos transformacionales normalmente incluyen una mezcla de intrusiones, unas cuantas instrucciones IF y PERFORM o DO y muchas instrucciones detalladas tales como MOVE y ADD. Estos módulos son inferiores en la estructura que los módulos de control.
Los módulos funcionales son los más bajos en la estructura, rara vez tiene un módulo subordinado bajos ellos. Solo desempeñan una tarea, tal como formatear, leer, calcular o escribir. Algunos de estos módulos se encuentran en un diagrama de flujo de datos, pero otros se tendrían que agregar, tal como leer un registro o imprimir una línea de error.
La figura 16.13 representa el diagrama de estructura para agregar las reservaciones para los huéspedes de un hotel. Los módulos 000, AGREGAR RESERVACIÓN DEL HUÉSPED y 100, AGREGAR RESERVACIÓN DEL CUARTO, son módulos de control que representan el programa entero (modulo 000) y proporcional el control necesario para hacer una reservación de cuarto (modulo100). El modulo 110, DESPLEGAR PANTALLA DE RESERVACIÓN, es un modulo funcional responsable de mostrar la pantalla de reservación inicial. Los módulos 120, OBTENER RESERVACIÓN DE CUARTO VÁLIDA, y 160, CONFIRMAR CONSERVACIÓN DEL CUARTO, son los módulos de control de nivel inferior
El modulo 120, OBTENER RESERVACIÓN DE CUARTO VÁLIDA, se desempeña relativamente hasta que los datos de la reservación sean válida o hasta que el operador de la reservación cancele la transacción. Este tipo de modulo OBTENER RESERVACIÓN… desahoga el modulo 100 de una cantidad considerable de código completo. Los módulos subordinados para OBTENER RESERVACIÓN DE CUATRO VÁLIDAD son módulos funcionales responsable de recibir la pantalla de reservación, editar o validar la reservación del cuarto y mostrad una pantalla de error si los datos de entrada no válidos. Debido a que estos módulos están en un bucle, el control permanece en esta parte de la estructura hasta que los datos de la pantalla sean válidos.
EL PRESENTE TEXTO ES SOLO UNA SELECCION DEL TRABAJO ORIGINAL.
PARA CONSULTAR LA MONOGRAFIA COMPLETA SELECCIONAR LA OPCION DESCARGAR DEL MENU SUPERIOR.
 Página anterior | Volver al principio del trabajo | Página siguiente  |